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A General Mechanism for RTP Header Extensions 


Abstract 


This document provides a general mechanism to use the header 
extension feature of RTP (the Real-time Transport Protocol). It 
provides the option to use a small number of small extensions in each 
RTP packet, where the universe of possible extensions is large and 
registration is decentralized. The actual extensions in use ina 
session are signaled in the setup information for that session. This 
document obsoletes RFC 5285. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
https://www.rfc-editor.org/info/rfc8285. 
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This document is subject to BCP 78 and the IETF Trust’s Legal 
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(https://trustee.ietf.org/license-info) in effect on the date of 
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Les 


Introduction 


The RTP specification [RFC3550] provides a capability to extend the 
RTP header. Section 5.3.1 of [RFC3550] defines the header extension 
format and rules for its use. The existing header extension method 
permits at most one extension per RTP packet, identified by a 16-bit 
identifier and a 16-bit length field specifying the length of the 
header extension in 32-bit words. 


This mechanism has two conspicuous drawbacks. First, it permits only 
one header extension in a single RTP packet. Second, the 
specification gives no guidance as to how the 16-bit header extension 
identifiers are allocated to avoid collisions. 


This specification removes the first drawback by defining a backward- 
compatible and extensible means to carry multiple header extension 
elements in a single RIP packet. It removes the second drawback by 
defining that these extension elements are named by URIs, defining an 
IANA registry for extension elements defined in IETF specifications, 
and providing a Session Description Protocol (SDP) method for mapping 
between the naming URIs and the identifier values carried in the RTP 
packets. 


This header extension applies to RTP/AVP (the Audio/Visual Profile) 
and its extensions. 


This document obsoletes [RFC5285] and removes a limitation from 
RFC 5285 that did not allow sending both one-byte and two-byte header 
extensions in the same RTP stream. 


Requirements Notation 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 


Design Goals 


The goal of this design is to provide a simple mechanism whereby 
multiple identified extensions can be used in RTP packets, without 
the need for formal registration of those extensions but nonetheless 
avoiding collisions. 


This mechanism provides an alternative to the practice of burying 
associated metadata into the media format bitstream. This has often 
been done in media data sent over fixed-bandwidth channels. Once 
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4. 


4. 


this is done, a decoder for the specific media format needs to 
extract the metadata. Also, depending on the media format, the 
metadata can be added at the time of encoding the media so that the 
bit-rate used for the metadata is taken into account. But the 
metadata can be unknown at that time. Inserting metadata at a later 
time can cause a decode and re-encode to meet bit-rate requirements. 


In some cases, a more appropriate and higher-level mechanism may be 
available, and if so, it can be used. For cases where a higher-level 
mechanism is not available, it is better to provide a mechanism at 
the RTP level than to have the metadata be tied to a specific form of 
media data. 


Packet Design 


1. General 


The following design is fit into the "header extension" of the RTP 
extension, as described above. 


The presence and format of this header extension and its contents are 
negotiated or defined out of band, such as through signaling (see 
below for SDP signaling). The 16-bit identifier for the two forms of 
the RTP extension defined here is only an architectural constant 
(e.g., for use by network analyzers); it is the negotiation/ 
definition (e.g., in SDP) that is the definitive indication that this 
header extension is present. 


The RIP specification [RFC3550] states that RTP "is designed so that 
the header extension may be ignored by other interoperating 
implementations that have not been extended." The intent of this 
restriction is that RTP header extensions MUST NOT be used to extend 
RTP itself in a manner that is backward incompatible with 


non-extended implementations. For example, a header extension is not 
allowed to change the meaning or interpretation of the standard RTP 
header fields or of the RTP Control Protocol (RTCP). Header 


extensions MAY carry metadata in addition to the usual RTP header 
information, provided the RTP layer can function if that metadata is 
missing. For example, RTP header extensions can be used to carry 
data that’s also sent in RTCP, as an optimization to lower latency, 
since they'll fall back to the original non-optimized behavior if the 
header extension is not present. The use of header extensions to 
convey information that will, if missing, disrupt the behavior of a 
higher-layer application that builds on top of RTP is only acceptable 
if this doesn’t affect interoperability at the RTP layer. For 
example, applications that use the SDP BUNDLE extension with the 
Media Identification (MID) RTP header extension [SDP-BUNDLE] to 
correlate RIP streams with SDP "m=" lines likely won’t work with full 
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functionality if the MID is missing, but the operation of the RTP 
layer of those applications will be unaffected. Support for RTP 
header extensions based on this memo is negotiated using, for 
example, SDP Offer/Answer [RFC3264]; intermediaries aware of the RTP 
header extensions are advised to be cautious when removing or 
generating RIP header extensions. See Section 4.7 of [RFC7667]. 


The RTP header extension is formed as a sequence of extension 
elements, with possible padding. Each extension element has a local 
identifier and a length. The local identifiers MAY be mapped to a 
larger namespace in the negotiation (e.g., session signaling). 


4.1.1. Transmission Considerations 


As is good network practice, data should only be transmitted when 
needed. The RTP header extension SHOULD only be present in a packet 
if that packet also contains one or more extension elements, as 
defined here. An extension element SHOULD only be present ina 
packet when needed; the signaling setup of extension elements 
indicates only that those elements can be present in some packets, 
not that they are in fact present in all (or indeed, any) packets. 


Some general considerations for getting the header extensions 
delivered to the receiver are as follows: 


1. The probability for packet loss and burst loss determines how 
many repetitions of the header extensions will be required to 
reach a targeted delivery probability, and if burst loss is 
likely, what distribution would be needed to avoid losing all 
repetitions of the header extensions in a single burst. 


2. If a set of packets are all needed to enable decoding, there is 
commonly no reason for including the header extension in all of 
these packets, as they share fate. Instead, at most one instance 
of the header extension per independently decodable set of media 
data would be a more efficient use of the bandwidth. 


3. How early the header extension item information is needed, from 
the first received RTP data or only after some set of packets are 
received, can guide whether the header extension(s) should be 
(1) in all of the first N packets or (2) included only once per 
set of packets -- for example, once per video frame. 
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4. The use of RTP-level robustness mechanisms, such as RTP 
retransmission [RFC4588] or Forward Error Correction (e.g., 
[RFC5109]) may treat packets differently from a robustness 
perspective, and header extensions should be added to packets 
that get a treatment corresponding to the relative importance of 
receiving the information. 


As a summary, the number of header extension transmissions should be 
tailored to a desired probability of delivery, taking the receiver 
population size into account. For the very basic case, N repetitions 
of the header extensions should be sufficient but may not be optimal. 
N is selected so that the header extension target delivery 
probability reaches 1-P*N, where P is the probability of packet loss. 
For point-to-point or small receiver populations, it might also be 
possible to use feedback, such as RTCP, to determine when the 
information in the header extensions has reached all receivers and 
stop further repetitions. Feedback that can be used includes the 
RTCP Extended Report (XR) Loss RLE Report Block [RFC3611], which will 
indicate successful delivery of particular packets. If the RTP/AVPF 
transport-layer feedback messages for generic NACK [RFC4585] are 
used, they can indicate failure to deliver an RTP packet with the 
header extension, thus indicating the need for further repetitions. 
The normal RTCP report blocks can also provide an indicator of 
successful delivery, if no losses are indicated for a reporting 
interval covering the RTP packets with the header extension. Note 
that loss of an RTCP packet reporting on an interval where RTP header 
extension packets were sent does not necessarily mean that the RIP 
header extension packets themselves were lost. 


4.1.2. Header Extension Type Considerations 


Each extension element in a packet has a local identifier (ID) anda 
length. The local identifiers present in the stream MUST have been 
negotiated or defined out of band. There are no static allocations 
of local identifiers. Each distinct extension MUST have a unique ID. 
The ID value 0 is reserved for padding and MUST NOT be used as a 
local identifier. 


An extension element with an ID value equal to 0 MUST NOT have an 
associated length field greater than 0. If such an extension element 
is encountered, its length field MUST be ignored, processing of the 
entire extension MUST terminate at that point, and only the extension 
elements present prior to the element with ID 0 and a length field 
greater than 0 SHOULD be considered. 


There are two variants of the extension: one-byte and two-byte 
headers. Since it is expected that (a) the number of extensions in 
any given RIP session is small and (b) the extensions themselves are 


Singer, et al. Standards Track [Page 6] 


RFC 8285 RTP Header Extensions October 2017 


small, the one-byte header form is preferred and MUST be supported by 
all receivers. A stream MUST contain only one-byte headers or only 
two-byte headers unless it is known that all recipients support 
mixing, by either SDP Offer/Answer [RFC3264] negotiation (see 

Section 6) or out-of-band knowledge. Each RTP packet with an RTP 
header extension following this specification will indicate whether 
it contains one-byte or two-byte header extensions through the use of 
the "defined by profile" field. Extension element types that do not 
match the header extension format, i.e., one-byte or two-byte, 

MUST NOT be used in that RTP packet. Transmitters SHOULD NOT use the 
two-byte header form when all extensions are small enough for the 
one-byte header form. Transmitters that intend to send the two-byte 
form SHOULD negotiate the use of IDs above 14 if they want to let the 
receivers know that they intend to use the two-byte form -- for 
example, if the RTP header extension is longer than 16 bytes. A 
transmitter may be aware that an intermediary may add RTP header 
extensions; in this case, the transmitter SHOULD use the two-byte 
form. 


A sequence of extension elements, possibly with padding, forms the 
header extension defined in the RTP specification. There are as many 
extension elements as will fit in the RTP header extension, as 
indicated by the RTP header extension length. Since this length is 
signaled in full 32-bit words, padding bytes are used to pad to a 
32-bit boundary. The entire extension is parsed byte by byte to find 
each extension element (no alignment is needed), and parsing stops 

(1) at the end of the entire header extension or (2) in the "one-byte 
headers only" case, on encountering an identifier with the reserved 
value of 15 -- whichever happens earlier. 


In both forms, padding bytes have the value of 0 (zero). They MAY be 
placed between extension elements, if desired for alignment, or after 
the last extension element, if needed for padding. A padding byte 
does not supply the ID of an element, nor does it supply the length 
field. When a padding byte is found, it is ignored, and the parser 
moves on to interpreting the next byte. 


Note carefully that the one-byte header form allows for data lengths 
between 1 and 16 bytes, by adding 1 to the signaled length value 
(thus, 0 in the length field indicates that one byte of data 
follows). This allows for the important case of 16-byte payloads. 
This addition is not performed for the two-byte headers, where the 
length field signals data lengths between 0 and 255 bytes. 


Use of RTP header extensions will reduce the efficiency of RTP header 
compression, since the header extension will be sent uncompressed 
unless the RTP header compression module is updated to recognize the 
extension header. If header extensions are present in some packets 
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but not in others, this can also reduce compression efficiency by 
requiring an update to the fixed header to be conveyed when header 
extensions start or stop being sent. The interactions of the RTP 
header extension and header compression are explored further in 
[RFC2508] and [RFC3095]. 


4.2. One-Byte Header 


In the one-byte header form of extensions, the 16-bit value required 
by the RTP specification for a header extension, labeled in the RTP 
specification as "defined by profile", MUST have the fixed bit 
pattern OxBEDE (the pattern was picked for the trivial reason that 
the first version of this specification was written on May 25th -- 
the feast day of the Venerable Bede). 


Each extension element MUST start with a byte containing an ID and a 
length: 


0 

Qn TE e233 6s 7 
+-+-+-+-+-+-+-+-+ 
| ID | len | 
+-+-+-+-+-+-+-+-+ 


The 4-bit ID is the local identifier of this element in the range 
1-14 inclusive. In the signaling section, this is referred to as the 
valid range. 


The local identifier value 15 is reserved for a future extension and 
MUST NOT be used as an identifier. If the ID value 15 is 
encountered, its length field MUST be ignored, processing of the 
entire extension MUST terminate at that point, and only the extension 
elements present prior to the element with ID 15 SHOULD be 
considered. 


The 4-bit length is the number, minus one, of data bytes of this 
header extension element following the one-byte header. Therefore, 
the value zero (0) in this field indicates that one byte of data 
follows, and a value of 15 (the maximum) indicates element data of 

16 bytes. (This permits carriage of 16-byte values, which is a 
common length of labels and identifiers, while losing the possibility 
of zero-length values, which would often be padded anyway.) 
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4. 


Bis 


An example header extension, with three extension elements and some 
padding, follows: 


0 I 2 3 
0 T234 6 PB Oe OD, VA 3 AS 0 PB r0 23) A O T OAO AL 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| OxBE | OxDE | length=3 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| mp atO] data | mp | t=1 | data... 
to—t—t—t-t-4t-4t-4+-4F-4F-4F-4-4-4-4-4-4-4-4-4-4-4-4 4-4-4 -t-tot-tat-tat 
-sedata | 0 (pad) | 0 (pad) | ID | 1=3 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +H 
| data | 


t—+—-+-4+-+-4+-4-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4t-4+-4-4-4+-4t-4-4-4-4+-4 
Two-Byte Header 


In the two-byte header form, the 16-bit value defined by the RTP 
specification for a header extension, labeled in the RTP 
specification as "defined by profile", is defined as shown below. 


0 1 
0123456789012345 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x100 |appbits | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The appbits field is 4 bits that are application dependent and MAY be 
defined to be any value or meaning; this topic is outside the scope 
of this specification. For the purposes of signaling, this field is 
treated as a special extension value assigned to the local identifier 
256. If no extension has been specified through configuration or 
signaling for this local identifier value (256), the appbits field 
SHOULD be set to all Os (zeros) by the sender and MUST be ignored by 
the receiver. 


Each extension element starts with a byte containing an ID and a byte 
containing a length: 


0 1 
01234567890123 45 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| ID | length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The 8-bit ID is the local identifier of this element in the range 
1-255 inclusive. In the signaling section, the range 1-256 is 
referred to as the valid range, with the values 1-255 referring to 
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extension elements and the value 256 referring to the 4-bit appbits 
field (above). Note that there is one ID space for both the one-byte 
form and the two-byte form. This means that the lower values (1-14) 
can be used in the 4-bit ID field in the one-byte header format with 
the same meanings. 


The 8-bit length field is the length of extension data in bytes, not 
including the ID and length fields. The value zero (0) indicates 
that there is no subsequent data. 


An example header extension, with three extension elements and some 
padding, follows: 


0 1 2 3 
O 1.2.3: 4-9-6) 7°38. 90-12. 3-45: 6.7 8-9-0 22 304 5-69 7-8. 9 0-1 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| 0x10 | 0x00 | length=3 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| ID | L=0 | ID | L=1 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| data | 0 (pad) | ID | L=4 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| data | 
+-+-+-+-+-+-+-+- +++ 


5. SDP Signaling Design 


The indication of the presence of this extension, and the mapping of 
local identifiers used in the header extension to a larger namespace, 
MUST be performed out of band -- for example, as part of an SDP 

Offer/Answer [RFC3264]. This section defines such signaling in SDP. 


A usable mapping MUST use IDs in the valid range, and each ID in this 
range MUST be used only once for each media section (or only once if 
the mappings are session level). Mappings that do not conform to 
these rules MAY be presented, for instance, during SDP Offer/Answer 
[RFC3264] negotiation as described in the next section, but remapping 
to conformant values is necessary before they can be applied. 


Each extension is named by a URI. That URI MUST be absolute; it 
precisely identifies the format and meaning of the extension. URIS 
that contain a domain name SHOULD also contain a month-date in the 
form mmyyyy. The definition of the element and assignment of the URI 
MUST have been authorized by the owner of the domain name on or very 
close to that date. (This avoids problems when domain names change 
ownership.) If the resource or document defines several extensions, 
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then the URI MUST identify the actual extension in use, e.g., using a 
fragment or query identifier (characters after a "#" or "?" in 
the URI). 


Rationale: The use of URIs provides for a large, unallocated space 
and gives documentation on the extension. The URIs do not have to be 
dereferencable, in order to permit confidential or experimental use, 
or to cover the case when extensions continue to be used after the 
organization that defined them ceases to exist. 


An extension URI with the same attributes MUST NOT appear more than 
once applying to the same stream, i.e., at session level or in the 
declarations for a single stream at media level. (The same extension 
can, of course, be used for several streams and can appear with 
different <extensionattributes> for the same stream.) 


For extensions defined in RFCs, the URI used SHOULD be a URN starting 
with "urn:ietf:params:rtp-hdrext:" followed by a registered, 
descriptive name. 


The registration requirements are detailed in Section 10 ("IANA 
Considerations"). 


An example where "avt-example-metadata" is the hypothetical name of a 
header extension might be: 


urn:ietf:params:rtp-hdrext:avt-example-metadata 
An example name not from the IETF might be: 
http: //example.com/082005/ext .htm#example-metadata 


The mapping MAY be provided per media stream (in the media-level 
section(s) of SDP, i.e., after an "m=" line) or globally for all 
streams (i.e., before the first "m=" line, at session level). The 
definitions MUST be either all session level or all media level; it 
is not permitted to mix the two styles. In addition, as noted above, 
the IDs used MUST be unique in each media section of the SDP or 
unique in the session for session-level SDP declarations. 
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Each local identifier potentially used in the stream is mapped to an 
extension identified by a URI using an attribute of the form: 


a=extmap:<value>["/"<direction>] <URI> <extensionattributes> 
where 


o <value> is the local identifier (ID) of this extension and is an 
integer in the valid range (0 is reserved for padding in both 
forms, and 15 is reserved in the one-byte header form, as noted 
above). 


o <direction> is one of "sendonly", "“recvonly", "sendrecv", or 
"inactive" (without the quotes) with relation to the device being 
configured. 


o <URI> is a URI, as above. 


The formal BNF syntax is presented in Section 8 of this 
specification. 


Example: 
a=extmap:1 http://example.com/082005/ext .htm#ttime 
a=extmap:2/sendrecv http://example.com/082005/ext .htm#xmeta short 


When SDP signaling is used for the RTP session, it is the presence of 
the "extmap" attribute(s) that is diagnostic that this style of 
header extensions is used, not the magic number ("BEDE" or "100") 
indicated above. 


6. SDP Signaling for Support of Mixed One-Byte and Two-Byte Header 
Extensions 


In order to allow for backward interoperability with systems that 

do not support the mixing of one-byte and two-byte header extensions, 
this document defines the "a=extmap-allow-mixed" Session Description 
Protocol (SDP) [RFC4566] attribute to indicate if the participant is 
capable of supporting this new mode. The attribute takes no value. 
This attribute can be used at the session level or the media level. 

A participant that proposes the use of this mode SHALL itself support 
the reception of mixed one-byte and two-byte header extensions. 


If SDP Offer/Answer [RFC3264] is supported and used, the negotiation 
for mixed one-byte and two-byte extensions MUST be negotiated using 
SDP Offer/Answer per [RFC3264]. In the absence of negotiations using 
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SDP Offer/Answer -- for example, when declarative SDP is used -- 
mixed headers MUST NOT occur unless the transmitter has some 
(out-of-band) knowledge that all potential recipients support 
this mode. 


The formal definition of this attribute is: 

Name: extmap-allow-mixed 

Value: None 

Usage Level: session, media 

Charset Dependent: No 

Example: 

a=extmap-allow-mixed 

When doing SDP Offer/Answer [RFC3264], an offering client that wishes 
to use both one-byte and two-byte extensions MUST include the 
attribute "a=extmap-allow-mixed" in the SDP offer. If 
"a=extmap-allow-mixed" is present in the SDP offer, the answerer that 
supports this mode and wishes to use it SHALL include the 
"a=extmap-allow-mixed" attribute in the answer. In the cases where 
the attribute has been excluded, both clients SHALL NOT use mixed 


one-byte and two-byte extensions in the same RTP stream but MAY use 
the one-byte or two-byte form exclusively (see Section 4.1.2). 


When used per [SDP-BUNDLE], this attribute is specified as the 
IDENTICAL category [SDP-MUX]. 


7. SDP Offer/Answer 


The simple signaling described above for the "extmap" attribute MAY 
be enhanced in an SDP Offer/Answer [RFC3264] context, to permit: 


o asymmetric behavior (extensions sent in only one direction), 

o the offer of mutually exclusive alternatives, or 

o the offer of more extensions than can be sent in a single session. 
A direction attribute MAY be included in an "extmap"; without it, the 
direction implicitly inherits, of course, from the stream direction 
or is "sendrecv" for session-level attributes or extensions of 


"inactive" streams. The direction MUST be one of "sendonly", 
"recvonly", "sendrecv", or "inactive" as specified in [RFC3264]. 
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Extensions, with their directions, MAY be signaled for an "inactive" 
stream. It is an error to use an extension direction incompatible 
with the stream direction (e.g., a "Sendonly" attribute fora 
"recvonly" stream). 


If an offer or answer contains session-level mappings (and hence no 
media-level mappings) and different behavior is desired for each 
stream, then the entire set of extension map declarations MAY be 
moved into the media-level section(s) of the SDP. (Note that this 
specification does not permit mixing global and local declarations, 
to make identifier management easier.) 


If an extension map is offered as "sendrecv", explicitly or 
implicitly, and asymmetric behavior is desired, the SDP answer MAY be 
changed to modify or add direction qualifiers for that extension. 


If an extension is marked as "sendonly" and the answerer desires to 
receive it, the extension MUST be marked as "recvonly" in the SDP 
answer. An answerer that has no desire to receive the extension or 
does not understand the extension SHOULD remove it from the SDP 
answer. An answerer MAY want to respond that he supports the 
extension and does not want to receive it at the moment, but he may 
indicate a desire to receive it in a future offer and will mark the 
extension as "inactive". 


If an extension is marked as "recvonly" and the answerer desires to 
send it, the extension MUST be marked as "sendonly" in the SDP 
answer. An answerer that has no desire to, or is unable to, send the 
extension SHOULD remove it from the SDP answer. An answerer MAY want 
to respond that he supports this extension but has no intention of 
sending it now; he may indicate a desire to send it in a future offer 
by marking the extension as "inactive". 


Local identifiers in the valid range inclusive in an offer or answer 
must not be used more than once per media section (including the 
session-level section). The local identifiers MUST be unique in an 
RTP session, and the same identifier MUST be used for the same 
offered extension in the answer. A session update MAY change the 
direction qualifiers of extensions being used. A session update MAY 
add or remove extension(s). Identifier values in the valid range 
MUST NOT be altered (remapped). 


Note that, under this rule, the same local identifier cannot be used 
for two extensions for the same media, even when one is "sendonly" 
and the other "recvonly", as it would then be impossible to make 
either of them "sendrecv" (since renumbering is not permitted 
either). 
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If a party wishes to offer mutually exclusive alternatives, then 
multiple extensions with the same identifier in the extended range 
4096-4351 MAY be offered. The answerer SHOULD select, at most, one 
of the offered extensions with the same identifier and remap it to a 
free identifier in the valid range for that extension to be usable. 


Similarly, if more extensions are offered than can be fit in the 
valid range, identifiers in the range 4096-4351 MAY be offered; the 
answerer SHOULD choose those that are desired and remap them to a 
free identifier in the valid range. 


An answerer may copy an "extmap" for an identifier in the extended 
range into the answer to indicate to the offerer that it supports 
that extension. Of course, such an extension cannot be used, since 
there is no way to specify it in an extension header. If needed, the 
offerer or answerer can update the session to assign a valid 
identifier to that extension URI. 


Rationale: The range 4096-4351 for these negotiation identifiers is 
deliberately restricted to allow expansion of the range of valid 


identifiers in the future. 


Either party MAY include extensions in the stream other than those 


negotiated, or those negotiated as "inactive" (for example, for the 

benefit of intermediate nodes). Only extensions that appeared with 

an identifier in the valid range in SDP originated by the sender can 
be sent. 


Example (port numbers, RTP profiles, payload IDs, rtpmaps, etc. all 
omitted for brevity): 


The offer: 


a=extmap:1 URI-toffset 
a=extmap:14 URI-obscure 
a=extmap:4096 URI-gps-string 
a=extmap:4096 URI-gps-binary 
a=extmap:4097 URI-frametype 
m=video 

a=sendrecv 

m=audio 

a=sendrecv 
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The answerer is interested in receiving GPS in string format only on 


video but cannot send GPS at all. It is not interested in 
transmission offsets on audio and does not understand the URI-obscure 
extension. It therefore moves the extensions from session level to 


media level and adjusts the declarations: 


m=video 

a=sendrecv 

a=extmap:1 URI-toffset 
a=extmap:2/recvonly URI-gps-string 
a=extmap:3 URI-frametype 

m=audio 

a=sendrecv 

a=extmap:1/sendonly URI-toffset 


When using [SDP-BUNDLE] to bundle multiple "m=" lines, the "extmap" 
attribute falls under the SPECIAL category of [SDP-MUX]. All the 
"m=" lines in a BUNDLE group are considered to be part of the same 
local identifier (ID) space. If an RTP header extension, i.e., a 
particular extension URI and configuration using 
<extensionattributes>, is offered in multiple "m=" lines that are 
part of the same BUNDLE group, it MUST use the same ID in all of 
these "m=" lines. Each "m=" line in a BUNDLE group can include 
different RTP header extensions allowing, for example, audio and 
video sources to use different sets of RTP header extensions. A 
difference in configuration using any of the <extensionattributes> is 
important. Unless an RTP header extension explicitly states 
otherwise, any such difference SHALL be communicated to all receivers 
and SHALL cause assignment of different IDs. An RTP header extension 
that does not follow this rule MUST explicitly define what would 
constitute compatible configurations that can be sent with the 


same ID. The directionality of the RTP header extensions in each 
"m=" line of the BUNDLE group is handled in the same way as handling 
for non-bundled "m=" lines. This allows for specifying different 


directionality for each of the repeated extension URIs in a BUNDLE 
group. 
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8. BNF Syntax 


The syntax definition below uses ABNF according to [RFC5234]. The 
syntax element "URI" is defined in [RFC3986] (only absolute URIs are 
permitted here). The syntax element "extmap" is an attribute as 


defined in [RFC4566], i.e., "a=" precedes the "extmap" definition. 
Specific <extensionattributes> are defined by the specification that 
defines a specific extension name; there can be several. 


Name: extmap 


Value: extmap-value 


Syntax: 
extmap-value = mapentry SP extensionname 
[SP extensionattributes] 
mapentry = "“extmap:" 1*5DIGIT ["/" direction] 
extensionname = URI 


extensionattributes = byte-string 

direction = "sendonly" / "recvonly" / "sendrecv" / "inactive" 

URI = <Defined in RFC 3986> 

byte-string = <Defined in RFC 4566> 

SP = <Defined in RFC 5234> 

DIGIT = <Defined in RFC 5234> 

9. Security Considerations 

This document defines only a place to transmit information; the 
security implications of each of the extensions must be discussed 
with those extensions. 
Extension usage is negotiated using [RFC3264], so integrity 
protection and end-to-end authentication MUST be implemented. The 
security considerations of [RFC3264] MUST be followed to prevent, for 
example, extension-usage blocking. 
Header extensions have the same security coverage as the RIP header 


itself. When the Secure Real-time Transport Protocol (SRTP) 
[RFC3711] is used to protect RTP sessions, the RTP payload can be 
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both encrypted and integrity protected, while the RTP header is 
either unprotected or integrity protected. In order to prevent DoS 
attacks (for example, by changing the header extension) integrity 
protection SHOULD be used. lLower-layer security protection such as 
Datagram Transport Layer Security (DTLS) [RFC6347] MAY be used. RTP 
header extensions can carry sensitive information for which 
participants in multimedia sessions want confidentiality. RFC 6904 
[RFC6904] provides a mechanism that extends the mechanisms of SRTP to 
selectively encrypt RTP header extensions in SRTP. 


The RIP application designer needs to consider their security needs, 
that includes cipher strength for SRTP packets in general and what 
that means for the integrity and confidentiality of the RTP header 
extensions. As defined by RFC 6904 [RFC6904], the encryption stream 
cipher for the header extension is dependent on the chosen SRTP 
cipher. 


Other options for securing RTP are discussed in [RFC7201]. 

10. IANA Considerations 
This document updates the references in three IANA registries to 
point to this document instead of RFC 5285, and updates and adds new 
SDP attributes in Sections 10.2 and 10.3, respectively. 

10.1. Identifier Space for IANA to Manage 
The mapping from the naming URI form to a reference to a 
specification is managed by IANA. Insertion into this registry is 


under the requirements of "Expert Review" as defined in [RFC8126]. 


TANA will also maintain a server that contains all of the registered 
elements in a publicly accessible space. 


Here is the formal declaration to comply with the IETF URN 
sub-namespace specification [RFC3553]. 


o Registry name: RTP Compact Header Extensions 
o Specification: RFC 5285 and RFCs updating RFC 5285 
o Information required: 

A. The desired extension naming URI 


B. A formal reference to the publicly available specification 
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A short phrase describing the function of the extension 


Contact information for the organization or person making the 
registration 


extensions defined in RFCs, the URI SHOULD be of the form 
ietf:params:rtp-hdrext:, and the formal reference is the RFC 


number of the RFC documenting the extension. 


o Review process: Expert Review is REQUIRED. The expert reviewer 
SHOULD check the following requirements: 


1. 


2: 


that the specification is publicly available; 


that the extension complies with the requirements of RTP, and 
this specification, for header extensions (specifically, that 
the header extension can be ignored or discarded without 
breaking the RTP layer); 


that the extension specification is technically consistent (in 
itself and with RTP), complete, and comprehensible; 


that the extension does not duplicate functionality in 
existing IETF specifications (including RTP itself) or other 
extensions already registered; 


that the specification contains a security analysis regarding 
the content of the header extension; 


that the extension is generally applicable -- for example, 
point-to-multipoint safe -- and the specification correctly 
describes limitations if they exist; 


that the suggested naming URI form is appropriately chosen and 
unique; and 


that for multiplexed "m=" lines [SDP-BUNDLE], any RTP header 
extension with differences in configurations of 
<extensionattributes> that do not require assignment of 
different IDs MUST explicitly indicate this and provide rules 
for what would constitute compatible configurations that can 
be sent with the same ID. 


o Size and format of entries: A mapping from a naming URI string to 
a formal reference to a publicly available specification, with a 
descriptive phrase and contact information. 


o Initial assignments: None 
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10.2. Registration of the SDP "extmap" Attribute 
IANA has updated the registration of the "extmap" SDP attribute 
[RFC4566] in the "att-field (both session and media level)" 
subregistry of the "Session Description Protocol (SDP) Parameters" 
registry. 


o Contact Name and email address: IETF, contacted via 
<mmusic@ietf.org> (or a successor address designated by the IESG) 


o Attribute Name: extmap 


o Attribute Syntax: See Section 8 of RFC 8285. 


o Attribute Semantics: The details of appropriate values are given 
in RFC 8285. 


o Usage Level: Media or session level 
o Charset Dependent: No 


o Purpose: Defines the mapping from the extension numbers used in 
packet headers into extension names. 


o Offer/Answer (O/A) Procedures: See Section 7 of RFC 8285. 
o MUX Category: SPECIAL 
o Reference: RFC 8285 
10.3. Registration of the SDP "extmap-allow-mixed" Attribute 
IANA has registered one new SDP attribute in the "att-field (both 
session and media level)" subregistry of the "Session Description 


Protocol (SDP) Parameters" registry: 


o Contact Name and email address: IETF, contacted via 
<mmusic@ietf.org> (or a successor address designated by the IESG) 


o Attribute Name: extmap-allow-mixed 

o Attribute Syntax: See Section 6 of RFC 8285. 

o Attribute Semantics: See Section 6 of RFC 8285. 
o Attribute Value: None 


o Usage Level: Media or session level 
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TI; 


L2 


12s 


o Charset Dependent: No 


o Purpose: Negotiate the use of one byte and two bytes in the same 
RTP stream. 


o O/A Procedures: See Section 6 of RFC 8285. 
o MUX Category: IDENTICAL 
o Reference: RFC 8285 

Changes from RFC 5285 


The major motivation for updating [RFC5285] was to allow having 
one-byte and two-byte RTP header extensions in the same RTP stream 
(but not in the same RTP packet). The support for this case is 
negotiated using a new SDP attribute, "extmap-allow-mixed", specified 
in this document. 


The other major change is to update the requirement from the RTP 
specifications [RFC3550] and [RFC5285] that the header extension "is 
designed so that the header extension may be ignored." This is 
described in Section 4.1. 


More text was added to Section 4.1.1 ("Transmission Considerations") 
to clarify when and how many times to send the RTP header extension 
to provide a higher probability of delivery. 


The Security Considerations section was expanded. 
The rest of the changes are editorial. 
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